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Abstract  Surveying  results  from  [5]  and  [6],  we  motivate  and  introduce  the  the¬ 
ory  behind  formalizing  rich  interfaces  for  software  and  hardware  compo¬ 
nents.  Rich  interfaces  specify  the  protocol  aspects  of  component  interac¬ 
tion.  Their  formalization,  called  interface  automata,  permits  a  compiler 
to  check  the  compatibility  of  component  interaction  protocols.  Interface 
automata  support  incremental  design  and  independent  implementabil- 
ity.  Incremental  design  means  that  the  compatibility  checking  of  inter¬ 
faces  can  proceed  for  partial  system  descriptions,  without  knowing  the 
interfaces  of  all  components.  Independent  implementability  means  that 
compatible  interfaces  can  be  refined  separately,  while  still  maintaining 
compatibility. 

Keywords:  Software  engineering,  formal  methods,  component-based  design. 

Introduction 

Interfaces  play  a  central  role  in  the  component-based  design  of  soft¬ 
ware  and  hardware  systems.  We  say  that  two  or  more  components  are 
compatible  if  they  work  together  properly.  Good  interface  design  is  based 
on  two  principles.  First,  an  interface  should  expose  enough  information 
about  a  component  as  to  make  it  possible  to  predict  if  two  or  more  com¬ 
ponents  are  compatible  by  looking  only  at  their  interfaces.  Second,  an 
interface  should  not  expose  more  information  about  a  component  than 
is  required  by  the  first  principle. 

The  technical  realization  of  these  principles  depends,  of  course,  on 
what  it  means  for  two  or  more  components  to  “work  together  properly.” 
A  simple  interpretation  is  offered  by  typed  programming  languages:  a 
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component  that  implements  a  function  and  a  component  that  calls  the 
function  are  compatible  if  the  function  dehnition  and  the  function  call 
agree  on  the  number,  order,  and  types  of  the  parameters.  We  discuss 
richer  notions  of  compatibility,  which  specify  in  addition  to  type  in¬ 
formation,  also  protocol  information  about  how  a  component  must  be 
used.  For  example,  the  interface  of  a  file  server  with  the  two  methods 
open-file  and  read-file  may  stipulate  that  the  method  read-file 
must  not  be  called  before  the  method  open-file  has  been  called.  Sym¬ 
metrically,  the  interface  of  a  client  specifies  the  possible  behaviors  of  the 
client  in  terms  of  which  orderings  of  open-file  and  read-file  calls 
may  occur  during  its  execution.  Given  such  server  and  client  interfaces, 
a  compiler  can  check  statically  if  the  server  and  the  client  fit  together. 

Interfaces  that  expose  protocol  information  about  component  interac¬ 
tion  can  be  specihed  naturally  in  an  automaton-based  language  [5].  In 
this  article,  we  give  a  tutorial  introduction  to  such  interface  automata. 

Interface  Languages 

We  begin  by  introducing  two  requirements  on  interface  languages.  An 
interface  language  should  support  incremental  design  and  independent 
implementability.  With  each  interface  language  we  present,  we  will  verify 
that  both  of  these  requirements  are  met. 

Incremental  design.  A  component  is  typically  an  open  system,  i.e., 
it  has  some  free  inputs,  which  are  provided  by  other  components.  In¬ 
cremental  design  is  supported  if  we  can  check  the  compatibility  of  two 
or  more  component  interfaces  without  specifying  interfaces  for  all  com¬ 
ponents,  i.e.,  without  closing  the  system.  The  unspecified  component 
interfaces  may  later  be  added  one  by  one,  as  long  as  throughout  the  pro¬ 
cess,  the  set  of  specified  interfaces  stays  compatible.  More  precisely,  the 
property  of  incremental  design  requires  that  if  the  interfaces  in  a  set  T 
(representing  the  complete,  closed  design)  are  compatible,  then  the  in¬ 
terfaces  in  every  subset  Q  (representing  a  partial,  open  design)  are 
compatible.  This  yields  an  existential  interpretation  of  interface  com¬ 
patibility;  the  interfaces  in  an  open  set  G  of  interfaces  (i.e.,  a  set  with 
free  inputs)  are  compatible  if  there  exists  an  interface  E  (representing 
an  environment  that  provides  all  free  inputs  to  the  interfaces  in  G)  such 
that  the  interfaces  in  the  closed  set  G  U  {E}  (without  free  inputs)  are 
compatible.^ 

Incremental  design  suggests  that  we  model  compatibility  as  a  symmet¬ 
ric  binary  relation  ~  between  interfaces,  and  composition  as  a  binary 
partial  function  ||  on  interfaces.  If  two  interfaces  F  and  G  are  com¬ 
patible,  that  is,  F  ^  G,  then  F\\G  is  defined  and  denotes  the  resulting 
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composite  interface.  Now  the  property  of  incremental  design  reads  as 
follows: 

For  all  interfaces  F,  G,  H ,  and  I,  if  F  ^  G  and  H  ^  I  and 
F\\G  ~  H\\I ,  then  F  ^  H  and  G  I  and  F\\H  ~  G\\F 

This  property  ensures  that  the  compatible  components  of  a  system  can 
be  put  together  in  any  order. ^ 

Independent  implementability.  Recall  the  first  principle  of  inter¬ 
face  design,  namely,  that  the  information  contained  in  interfaces  should 
suffice  to  check  if  two  or  more  components  are  compatible.  This  principle 
can  be  formalized  as  follows:  if  F  and  G  are  compatible  interfaces,  and 
F'  is  a  component  that  conforms  to  interface  F,  and  G’  is  a  component 
that  conforms  to  interface  G,  then  F'  and  G'  are  compatible  components, 
and  moreover,  the  composition  F'\\G'  of  the  two  components  conforms  to 
the  composite  interface  F\\G.  We  call  this  the  property  of  independent 
implementability,  because  it  enables  the  outsourcing  of  the  implementa¬ 
tion  of  the  components  F'  and  G'  to  two  different  vendors:  as  long  as 
the  vendors  conform  to  the  provided  interfaces  F  and  G,  respectively, 
their  products  will  fit  together,  even  if  the  vendors  do  not  communicate 
with  each  other. 

For  simplicity,  in  this  article  we  gloss  over  the  differences  between 
interfaces  and  components,  and  express  both  in  the  same  language;  that 
is,  we  consider  components  to  be  simply  more  detailed  interfaces.^  For 
this  purpose,  we  use  a  refinement  preorder  between  interfaces:  if  F  ^  F' , 
then  the  interface  F'  refines  the  interface  F.  An  interface  may  be  refined 
into  an  implementation  in  several  steps.  As  the  refinement  relation  is  a 
preorder,  it  is  transitive.  The  property  of  independent  implementability 
reads  as  follows: 

For  all  interfaces  F,  F' ,  G,  and  G' ,  if  F  G  and  F  F  F' 
andGhG',  then  F' G'  and  F\\G  h  F'\\G'. 

This  property  ensures  that  compatible  interfaces  can  always  be  refined 
separately.^ 

Assume / Guarantee  Interfaces 

We  illustrate  the  properties  of  incremental  design  and  independent 
implementability  through  a  simple,  stateless  interface  language  called 
assume/guarantee  (A/G,  for  short)  interfaces  [6].  Assume/guarantee  in¬ 
terfaces  have  input  and  output  variables.  An  A/G  interface  puts  a  con¬ 
straint  on  the  environment  through  a  predicate  on  its  input  variables: 
the  environment  is  expected  to  provide  inputs  that  satisfy  ■  In  return. 
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the  interface  communicates  to  the  environment  a  constraint  on  its 
output  variables:  it  vouches  to  provide  only  outputs  that  satisfy  .  In 
other  words,  the  input  assumption  represents  a  precondition,  and  the 
output  guarantee  a  postcondition. 

Definition  1  An  A/G  interface  F  =  {X^ ,  ,p^ ,p‘^)  consists  of 

■  two  disjoint  sets  X^  and  X^  of  input  and  output  variables; 

■  a  satisfiable  predicate  p^  over  X^  ealled  input  assumption; 

■  a  satisfiable  predicate  p^  over  X^  ealled  output  guarantee. 

Note  that  input  assumptions,  like  output  guarantees,  are  required  to 
be  satisfiable,  not  valid.  An  input  assumption  is  satisfiable  if  it  can  be 
met  by  some  environment.  Hence,  for  every  A/G  interface  there  is  a 
context  in  which  it  can  be  used.  On  the  other  hand,  in  general  not  all 
environments  will  satisfy  the  input  assumption;  that  is,  the  interface 
puts  a  constraint  on  the  environment. 

Example  2  A  division  eomponent  with  two  inputs  x  and  y,  and  an 
output  z,  might  have  an  A/G  interface  with  the  input  assumption  y  /  Q 
and  the  output  guarantee  true  (which  is  trivially  satisfied  by  all  output 
values).  The  input  assumption  y  /  0  ensures  that  the  component  is  used 
only  in  eontexts  that  provide  non-zero  divisors. 

In  the  following,  when  referring  to  the  components  of  several  inter¬ 
faces,  we  use  the  interface  name  as  subscript  to  identify  ownership.  For 
example,  the  input  assumption  of  an  interface  F  is  denoted  by  p/. 

Compatibility  and  composition.  We  define  the  composition  of 
A/G  interfaces  in  several  steps.  First,  two  A/G  interfaces  are  syntacti¬ 
cally  composable  if  their  output  variables  are  disjoint.  In  general,  some 
outputs  of  one  interface  will  provide  inputs  to  the  other  interface,  and 
some  inputs  will  remain  free  in  the  composition.  Second,  two  A/G  in¬ 
terfaces  F  and  G  are  semantically  compatible  if  whenever  one  interface 
provides  inputs  to  the  other  interface,  then  the  output  guarantee  of  the 
former  implies  the  input  assumption  of  the  latter.  Consider  first  the 
closed  case,  that  all  inputs  of  F  are  outputs  of  G,  and  vice  versa.  Then 
F  and  G  are  compatible  if  the  closed  formula 

(yXp  G  Xq){p‘p  f\  p'q  p/aPq)  {/) 

is  true.  In  the  open  case,  where  some  inputs  of  F  and  G  are  left  free, 
the  formula  {/)  has  free  input  variables.  As  discussed  above,  to  support 
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incremental  design,  the  two  interfaces  F  and  G  are  compatible  if  they 
can  be  used  together  in  some  context,  i.e.,  if  there  is  a  environment 
that  makes  {^f)  true  by  providing  helpful  input  values.  Thus,  in  the 
open  case,  the  A/G  interfaces  F  and  G  are  compatible  if  the  formula 
(V^)  is  satisfiable.  Then,  the  formula  {^f)  is  the  input  assumption  of  the 
composite  interface  F\\G,  because  it  encodes  the  weakest  condition  on 
the  environment  of  F\\G  that  makes  F  and  G  work  together. 

Definition  3  Two  A/G  interfaces  F  and  G  are  composable  if  Xp  n 
Xq  =  0.  Two  A/G  interfaces  F  and  G  are  compatible,  written  F  ^  G, 
if  they  are  composable  and  the  formula 

{yXp  U  XQ){(j)p  A  (j)Q  (f/Afo)  {/) 

is  satisfiable.  The  composition  F\\G  of  two  compatible  A/G  interfaces 
F  and  G  is  the  A/G  interface  with 

■  K\\g  = 

■  ^F\\G  = 

■  ^F\\G  ~ 

■  ^^\\G  ~  f>F^^G- 

Note  that  the  compatibility  relation  ~  is  symmetric. 

Example  4  Let  F  be  the  A/G  interface  without  input  variables,  the 
single  output  variable  x,  and  the  output  guarantee  true.  Let  G  be  the 
A/G  interface  with  the  two  input  variables  x  and  y,  the  input  assumption 
X  =  0  y  =  0,  and  no  output  variables.  Then  F  and  G  are  compatible, 
because  the  formula 

(Vx)(true  ^  (x  =  0  ^  y  =  0)) 

simplifies  to  y  =  0,  which  is  satisfiable.  Note  that  the  predicate  y  =  0 
expresses  the  weakest  input  assumption  that  the  composite  interface  needs 
to  make  in  order  to  ensure  that  the  input  assumption  x  =  0  =i>  y  =  0 
of  G  is  satisfied.  This  is  because  F  makes  no  guarantees  about  x;  in 
particular,  it  might  provide  outputs  x  that  are  0,  and  it  might  provide 
outputs  X  that  are  different  from  0. 

The  composition  F\\G  has  the  input  variable  y,  the  input  assumption 
y  =  0,  the  output  variable  x,  and  the  output  guarantee  true. 

The  following  theorem  shows  that  the  A/G  interfaces  support  incre¬ 
mental  design. 
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Theorem  5  For  all  A/G  interfaces  F,  G,  H,  and  I,  if  F  G  and 
Hr~.IandF\\G  ~  H\\I ,  then  F  r-.  H  and  G  I  and  F\\H  ~  G\\L 


Proof  sketch.  Note  that  from  the  premises  of  the  theorem  it  follows 
that  (1)  the  four  sets  Xp,  Xq,  Xp,  and  X^  are  pairwise  disjoint;  and 
(2)  the  formula 

(yXp  U  Xq  U  Xp  U  X^){(f)p  A  (f)Q  A  A  ^  (j)^p  A  (^q  A  (f>p[  A  (f>j) 


is  satisfiable.  To  prove  from  this  that,  say,  the  formula 
{\/Xp  U  Xff){(j)p  A  (pp  (ppAfiff) 


is  satisfiable,  choose  the  values  for  the  variables  in  Xp^^p  HXq^^j 
(j)Q  A  (t)f  is  true.  □ 


so  that 


Refinement.  Besides  composition,  the  second  operation  on  inter¬ 
faces  is  refinement.  Refinement  between  A/G  interfaces  is,  like  subtyp¬ 
ing  for  function  types,  defined  in  an  input /output  contravariant  fashion: 
an  implementation  must  accept  all  inputs  that  the  specification  accepts, 
and  it  may  produce  only  outputs  that  the  specification  allows.  Hence, 
to  refine  an  A/G  interface,  the  input  assumption  can  be  weakened,  and 
the  output  guarantee  can  be  strengthened. 

Definition  6  An  A/G  interface  F'  refines  an  A/G  interface  F,  written 
F  A  F',  if 

1.  x/c  X/,  and  X^  D  X/,; 

2.  (j)/  (f)/,  and  (j)/ 

Refinement  between  A/G  interfaces  is  a  preorder  (i.e.,  reflexive  and 
transitive).  The  following  theorem  shows  that  the  A/G  interfaces  sup¬ 
port  independent  implementability. 

Theorem  7  For  all  A/G  interfaces  F,  G,  and  F' ,  if  F  G  and  F  A 
F',  then  F' G  and  F\\G  h  F'\\G. 

Proof  sketch.  From  Xp  n  Xq  =  0  and  Xp  D  X/,,  it  follows  that 
Xp,  n  Xq  =  0.  Ghoose  values  for  the  input  variables  in  Xp.^^Q  so  that 

iy Xp  \J  Xq){(I)p  A  (J/q  ^  //A(Pq). 

From  Xp  C  X/,  and  Xp  D  Xp,,  it  follows  that  Xpt^t^Q  C  Choose 

arbitrary  values  for  all  variables  not  in  Then  0/^,  A0g  4>/,a4>q 
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follows  from  ^  and  (j)p  A  (j)Q  4>g  ^  ^F'  ■  This 

proves  that  F'  ~  G.  The  proof  that  F\\G  F  -F'||G  is  straight-forward. 
□ 


Note  that  the  contravariant  definition  of  refinement  is  needed  for  The¬ 
orem  7  to  hold,  as  input  assumptions  and  output  guarantees  occur  on 
two  different  sides  of  the  implication  in  the  formula  (■0). 

We  have  not  fixed  the  types  of  variables,  nor  the  theory  in  which  input 
assumptions  or  output  guarantees  are  written.  Checking  the  compatibil¬ 
ity  of  A/G  interfaces,  and  checking  refinement  between  A/G  interfaces, 
requires  a  procedure  that  decides  the  satisfiability  of  universal  formulas 
in  that  theory.  For  example,  if  all  variables  are  boolean,  then  the  input 
assumptions  and  output  guarantees  are  quantifier-free  boolean  formulas. 
In  this  case,  compatibility  checking  requires  the  evaluation  of  3V  boolean 
formulas  (namely,  satisfiability  checking  of  the  universal  formula  {'ip)), 
and  refinement  checking  requires  the  evaluation  of  V  boolean  formulas 
(namely,  validity  checking  of  the  two  implications  of  Definition  6). 

Automaton  Interfaces 

We  now  present  the  stateful  interface  language  called  interface  au¬ 
tomata  [5].  An  interface  automaton  is  an  edge-labeled  digraph  whose 
vertices  represent  interface  states,  whose  edges  represent  interface  tran¬ 
sitions,  and  whose  labels  represent  action  names.  The  actions  are  parti¬ 
tioned  into  input,  output,  and  internal  actions.  The  internal  actions  are 
“hidden”:  they  cannot  be  observed  by  the  environment.  The  syntax  of 
interface  automata  is  identical  to  the  syntax  of  I/O  automata  [8],  but 
composition  will  be  defined  differently. 

Definition  8  An  interface  automaton  F  =  {Q,q^,A^,A^,A^,5)  con¬ 
sists  of 

■  a  finite  set  Q  of  states; 

■  an  initial  state  G  Q; 

■  three  pairwise  disjoint  sets  Afi  A^,  and  A^  o/ input,  output,  and 
hidden  actions; 

■  a  set  dCQxAxQ  of  transitions,  where  A  =  A-^  U  A^  U  A^  is 
the  set  of  all  actions. 

IFe  require  that  the  automaton  F  be  input-deterministic,  that  is,  for  all 
states  q,q',q"  €  Q  and  all  input  actions  a  G  A^ ,  if  {q,a,q')  G  5  and 
{q,a,q")  G  5,  then  q'  =  q" . 


trnsmt 


ack 


nack 


Figure  1.  The  interface  automaton  Try  Twice. 


Figure  2.  The  interface  automaton  Client. 

An  action  a  G  A  is  enabled  at  a  state  q  G  Q  ii  there  exists  a  state 
q'  G  Q  such  that  {q,  a,  q')  G  5.  Given  a  state  q  G  Q,  we  write  A\q)  (resp. 
A^{q);  A^{q))  for  the  set  of  input  (resp.  output;  hidden)  actions  that 
are  enabled  at  q.  Unlike  I/O  automata,  an  interface  automaton  is  not 
required  to  be  input-enabled;  that  is,  we  do  not  require  that  A^ (q)  =  A^ 
for  all  states  q  G  Q.  Rather,  we  use  the  set  A^ (q)  to  specify  the  input 
actions  that  are  accepted  at  state  g;  that  is,  an  interface  automaton 
encodes  the  assumption  that,  when  F  is  in  state  q,  the  environment 
does  not  provide  an  input  action  that  is  not  enabled  at  q. 

Example  9  We  model  a  software  component  that  implements  a  message- 
transmission  service.  The  component  has  a  method  “send”  for  sending 
messages.  When  this  method  is  called,  the  component  returns  either 
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“ok”  or  “fail.  ”  To  perform  this  service,  the  component  relies  on  a  com¬ 
munication  channel  that  provides  the  method  “trnsmt”  for  transmitting 
messages.  The  two  possible  return  values  are  “ack,  ”  which  indicates  a 
successful  transmission,  and  “nack,  ”  which  indicates  a  failure.  When  the 
method  “send”  is  called,  the  component  tries  to  transmit  the  message, 
and  if  the  first  transmission  fails,  it  tries  again.  If  both  transmissions 
fail,  the  component  reports  failure.  The  interface  automaton  modeling 
this  component  is  called  Try  Twice  and  shown  in  Figure  1. 

The  interface  automaton  TryTwice  has  the  three  input  actions  “send,” 
“ack,”  and  “nack”;  the  three  output  actions  “trnsmt,”  “ok,”  and  “fail”; 
and  no  hidden  actions.  It  has  seven  states,  with  state  0  being  initial 
(marked  by  an  arrow  without  source).  On  the  transitions,  we  append 
to  the  name  of  the  action  label  the  symbol  (resp.  “!”;  “;”)  to  in¬ 
dicate  that  the  transition  is  input  (resp.  output;  hidden).  Note  how  the 
automaton  expresses  in  a  straight-forward  manner  the  above  informal 
description  of  the  message-passing  service.  The  input  “send”  is  accepted 
only  in  state  0;  that  is,  the  component  expects  a  client  to  send  a  second 
message  only  after  it  has  received  an  “ok”  or  “fail”  response. 

The  interface  automaton  Client  of  Figure  2  shows  a  possible  client  of 
the  message-passing  service.  It  has  the  input  actions  “ok”  and  “fail,” 
the  output  action  “send,  ”  and  again  no  hidden  actions.  This  particular 
client  expects  messages  to  be  sent  successfully,  and  makes  no  provisions 
for  handling  failures:  after  calling  the  method  “send,”  it  accepts  the 
return  value  “ok,  ”  but  does  not  accept  the  return  value  “fail.  ”  The  ex¬ 
pectation  that  the  return  value  is  always  “ok”  is  an  assumption  by  the 
component  Client  about  its  environment;  that  is,  the  component  Client  is 
designed  to  be  used  only  with  message-transmission  services  that  cannot 
fail. 


An  interface  automaton  F  is  closed  if  it  has  no  input  and  output 
actions;  that  is,  if  =  0.  Closed  interface  automata  do  not 

interact  with  the  environment. 

An  execution  of  the  interface  automaton  A  is  a  finite  alternating  se¬ 
quence  qQ,ao,qi,ai, . . .  ,qn  oi  states  and  actions  such  that  (g*,  ai,  qi+i)  G 
5  for  all  0  <  f  <  n.  The  execution  is  autonomous  if  all  its  actions  are 
output  or  hidden  actions;  that  is,  if  Oi  G  A^  U  A^  for  all  0  <  i  <  n.  Au¬ 
tonomous  executions  do  not  depend  on  input  actions.  The  execution  is 
invisible  if  all  its  actions  are  hidden;  that  is,  if  a*  G  A^  for  all  0  <  f  <  n. 
A  state  q'  G  Q  is  {autonomously,  invisibly)  reachable  from  a  state  q  G  Q 
if  there  exists  an  (autonomous;  invisible)  execution  whose  first  state  is  q, 
and  whose  last  state  is  q' .  The  state  q'  is  reachable  in  F  if  q'  is  reachable 
from  the  initial  state  q^.  In  the  definition  of  interface  automata,  it  is 
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not  required  that  all  states  be  reachable.  However,  one  is  generally  not 
interested  in  states  that  are  not  reachable,  and  they  can  be  removed. 

Compatibility  and  composition.  We  define  the  composition  of 
two  interface  automata  only  if  their  actions  are  disjoint,  except  that  an 
input  action  of  one  automaton  may  coincide  with  an  output  action  of 
the  other  automaton. 

Definition  10  Two  interface  automata  F  and  G  are  composable  if 

1.  A^r\AG  =  %  and  Ap  D  A^  =  0; 

2.  A^pnA{j  =  0; 

3.  A^nA2  =  0. 

For  two  interface  automata  F  and  G,  we  let  shared {F,G)  =  Ap  ri 
Aq  be  the  set  of  common  actions.  If  F  and  G  are  composable,  then 
shared{F,G)  =  {Aq  n  A^)  U  {A^  fl  Aq).  We  define  the  composition 
of  interface  automata  in  stages,  first  defining  the  product  automaton 
F  ®G.  The  two  automata  synchronize  on  the  actions  in  shared{F,G), 
and  asynchronously  interleave  all  other  actions.  Shared  actions  become 
hidden  in  the  product. 

Definition  11  For  two  composable  interface  automata  F  and  G,  the 
product  F  0  G  is  the  interface  automaton  with 

■  Qf®g  =  Qf  X  Qg; 

■  9f®G  = 

■  ^F®G  =  {Ap'J  Ajj)\shared{F,G); 

■  ^F®G  =  {A^^A^)\shared{F,G); 

■  Ap^Q  =  Ap  U  Aq  U  shared  {F,  G); 

■  ((?,  r),  a,  {q',r'))  G  Sp^G  iff 

a  ^  shared  {F,  G)  and  {q,  a,  q')  €  Sp  and  r  =  r' ,  or 
a  0  shared{F,  G)  and  q  =  q'  and  (r,  a,  r')  G  5g,  or 
a  G  shared  {F^G)  and  {q,a,q')  €  Sp  and  {r,a,r')  G  Sg- 

Let  5p  =  {{q,  a,  g')  G  5  |  a  G  Ap}  denote  the  set  of  input  transitions  of 
an  interface  automaton  F,  and  let  5p  and  5p  be  defined  similarly  as  the 
output  and  hidden  transitions  of  F.  Then  according  to  the  definition  of 
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Figure  3.  The  product  automaton  TryTwice  ®  Client. 


product  automata,  each  input  transition  of  F  0  G  is  an  input  transition 
of  either  F  or  G;  that  is,  {{q,r),a,  {q',r'))  G 

{q,  a,  q')  G  5p  and  a  0  and  r  =  r';  or 
a  0  A‘p  and  q  =  q'  and  (r,  a,  r')  G  5q. 

Each  output  transitions  of  E  (8)  G  is  an  output  transition  of  F  or  G;  that 
is,  {{q,  r),  a,  {q' ,r'))  G  iff 

{q,  a,  q')  G  6p  and  a  fL  Aq  and  r  =  r';  or 
a  0  Ap  and  q  =  q'  and  (r,  a,  r')  G 

Each  hidden  transition  of  E  (8)  G  is  either  an  input  transition  of  E  that 
is  an  output  transition  of  G,  or  vice  versa,  or  it  is  a  hidden  transition  of 
E  or  G;  that  is,  {{q,  r),  a,  (g',  r'))  G  iff 

{q,a,q')  G  dp  and  {r,a,r')  €  dp ;  or 
(q,a,q')  G  dp  and  {r,a,r')  G  dp;  or 
{q,  a,  q')  G  dp  and  r  =  r';  or 
q  =  q'  and  (r, a, r')  G  dp. 

Example  12  E/ie  product  TryTwice®  Client  of  the  interfaee  automata 
TryTwiee  and  Client  from  Figures  1  and  2  is  shown  in  Figure  3.  Eaeh 
state  of  the  product  consists  of  a  state  of  TryTwice  together  with  a  state 
of  Client.  Only  the  reachable  states  of  the  produet  automaton  are  shown. 
Each  transition  of  the  product  is  either  a  joint  “send”  transition,  which 
represents  the  call  of  the  method  “send”  by  Client,  or  a  joint  “ok”  transi¬ 
tion,  which  represents  the  termination  of  the  method  “send”  with  return 
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Figure  4-  The  composite  interface  automaton  TryTwice\\Client. 

value  “ok,”  or  a  transition  of  TryTwice  calling  the  method  “trnsmt”  of 
the  (unspecified)  communication  channel,  or  a  transition  of  TryTwice 
receiving  the  return  value  “ack”  or  “nack”  from  the  channel. 

Consider  the  following  sequence  of  events.  The  component  Client  calls 
the  method  “send”;  then  TryTwice  calls  twice  the  method  “trnsmt”  and 
receives  twice  the  return  value  “nack,  ”  indicating  transmission  failure. 
This  sequence  of  events  brings  us  to  state  6  of  the  product  automa¬ 
ton,  which  corresponds  to  state  6  of  TryTwice  and  state  1  of  Client. 
In  state  6,  the  component  TryTwice  tries  to  report  failure  by  returning 
“fail,  ”  hut  not  expecting  failure,  the  component  Client  does  not  accept  the 
return  value  “fail”  in  state  1.  Hence  the  product  state  6  has  no  outgoing 
edges;  it  is  called  an  error  state,  because  at  product  state  6,  the  compo¬ 
nent  TryTwice  violates  the  assumption  made  by  the  component  Client 
about  the  inputs  that  Client  receives. 

This  example  illustrates  that,  as  interface  automata  are  not  necessar¬ 
ily  input-enabled,  in  the  product  of  two  interface  automata,  one  of  the 
automata  may  produce  an  output  action  that  is  in  the  input  alphabet 
of  the  other  automaton,  but  is  not  accepted. 

Definition  13  Civen  two  composable  interface  automata  F  and  G,  a 
product  state  {q,r)  G  Qp  x  Qg  is  an  error  state  of  the  product  automa¬ 
ton  F  ®  G  if  there  exists  an  action  a  G  shared  {F,G)  such  that  either 
a  €  Ap{q)  and  a  ^  AQ{r),  or  a  ^  Ap{q)  and  a  G  write 

error  {F,  G)  for  the  set  of  error  states  of  the  product  automaton  F  G. 

If  the  product  F  0G  contains  no  reachable  error  states,  then  the  two 
interface  automata  F  and  G  satisfy  each  other’s  input  assumptions  and 
are  thus  compatible.  On  the  other  hand,  if  T  0  G  is  closed  and  contains 
a  reachable  error  state,  then  F  and  G  are  incompatible.  The  interesting 
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case  arises  when  F contains  reachable  error  states,  but  is  not  closed. 
The  fact  that  a  state  in  error  {F,G)  is  reachable  does  not  necessarily 
indicate  an  incompatibility,  because  by  providing  appropriate  inputs, 
the  environment  of  F  ^  G  may  be  able  to  ensure  that  no  error  state  is 
encountered  in  the  product.  We  therefore  define  the  set  of  incompatible 
states  of  F  0  G  as  those  states  from  which  no  environment  can  prevent 
that  an  error  state  may  be  entered.  First,  the  error  states  of  F  G 
are  incompatible.  Second,  all  states  from  which  a  sequence  of  output  or 
hidden  actions  of  F  G  leads  to  an  error  state  are  also  incompatible, 
because  the  product  automaton  may  choose  to  traverse  that  sequence  in 
every  environment.  On  the  other  hand,  if  an  error  state  is  only  reachable 
via  an  input  action,  then  a  helpful  environment  can  choose  not  to  provide 
that  action,  thus  avoiding  the  error  state. 

Definition  14  Given  two  composable  interface  automata  F  and  G,  a 
product  state  {q,r)  G  Qf  x  Qg  is  a  compatible  state  of  the  produet 
automaton  F<SiG  if  there  exists  no  error  state  {q',r')  €  error {F,G)  that 
is  autonomously  reachable  from  {q,  r) .  Two  interfaee  automata  F  and 
G  are  compatible,  written  F  ^  G,  if  they  are  composable  and  the  initial 
state  of  the  product  automaton  F  ^  G  is  compatible. 

Note  that  the  compatibility  relation  ~  is  symmetric. 

If  two  composable  interface  automata  F  and  G  are  compatible,  then 
there  is  an  environment  E  such  that 

(1)  E  is  composable  with  E  0  G; 

(2)  {E  ^G)  E  is  closed; 

(3)  for  all  states  {{q,  r),s)  G  {Qf  x  Qg)  xQe  that  are  reach¬ 
able  in  {E  ®  G)  ®  E,  we  have  {q,r)  fL  error{E,G)  and 
{{q,r),s)  0  error{F  0  G,  E). 

The  third  condition  ensures  that  (3a)  E  prevents  the  error  states  of  E0G 
from  being  entered,  and  (3b)  E  accepts  all  outputs  of  F(8)G  and  does  not 
provide  inputs  that  are  not  accepted  hy  E  ^G.  An  interface  automaton 
that  satisfies  the  conditions  (l)--(3)  is  called  a  legal  environment  for 
T  (8)  G.  The  existence  of  a  legal  environment  shows  that  two  compatible 
interfaces  can  be  used  together  in  some  context. 

For  compatible  interface  automata  E  and  G,  there  is  always  a  trivial 
legal  environment,  which  provides  no  inputs  to  F  iD  G.  Formally,  empty 
closure  of  F  and  G  is  the  interface  automaton  close{F,G)  with 

Qclose{F,G)  =  {0}; 

^dose{F,G)  ~ 
aI  —  aO 

^close(F,G)  ~  ^F(S)G^ 
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^close(F,G) 

^close(F,G) 

^close{F,G) 


^F®G-' 

0; 

{(0,  a,  0)  I  a  G  ^iiose{F,G)^- 


The  empty  closure  close{F,G)  has  a  single  state  (arbitrarily  named  0), 
which  is  its  initial  state.  It  accepts  all  output  actions  oi  F  0  G  as 
inputs,  but  does  not  issue  any  outputs.  All  states  that  are  reachable  in 
(F  (g)  G)  0  close  {F,  G)  are  reachable  solely  by  output  and  hidden  actions 
of  F  (g)  G.  Thus,  if  the  initial  state  of  F  (g)  G  is  compatible,  then  each 
state  that  is  reachable  in  (F  (g)  G)  (g)  close  (F,  G)  must  not  correspond  to 
an  error  state  of  F  (g  G.  On  the  other  hand,  if  the  initial  state  of  F  ig)  G 
is  not  compatible,  then  some  error  state  of  F  (g)  Q  is  reachable  in  every 
environment  that  does  not  constrain  the  outputs  of  Fig) G,  in  particular, 
in  (F  (g)  G)  ig)  close{F,  G).  Consequently,  two  interface  automata  F  and 
G  are  compatible  iff  for  all  states  {q,r)  £  Q p  x  Qg  such  that  ((g,  r),0) 
is  reachable  in  (F  (g  G)  (g)  close{F,G),  we  have  {q,r)  0  error{F,G). 

The  composition  of  two  compatible  interface  automata  is  obtained  by 
restricting  the  product  of  the  two  automata  to  the  set  of  compatible 
states. 


Definition  15  Given  two  compatible  interface  automata  F  and  G,  the 
composition  F||G  is  the  interface  automaton  that  results  from  the  prod¬ 
uct  F  ®  G  by  removing  all  transitions  {q,a,q')  G  such  that 

1.  q  is  a  compatible  state  of  the  product  F  ig)  G; 

2.  a  G  Ap^G  input  action  of  the  product; 

3.  q’  is  not  a  compatible  state  of  F  ®  G. 

Example  16  /n  the  product  automaton  Try  Twice  (g)  Client  from  Fig¬ 
ure  3,  state  6  is  an  error  state,  and  thus  not  compatible.  However,  the 
product  Try  Twice  g)  Client  is  not  closed,  because  its  environment  — the 
communication  channel —  provides  “ack”  and  “nack”  inputs.  The  en¬ 
vironment  that  provides  input  “ack”  (or  no  input  at  all)  at  the  product 
state  4  ensures  that  the  error  state  6  is  not  entered.  Hence,  the  prod¬ 
uct  states  0,  1,  2,  3,  4,  o-nd  5  are  compatible.  Since  the  initial  state  0 
of  the  product  is  compatible,  the  two  interface  automata  Try  Twice  and 
Client  are  compatible.  The  result  of  removing  from  Try  Twice®  Client  the 
input  transition  to  the  incompatible  state  6  is  the  interface  automaton 
Try Twice\\  Client  shown  in  Figure  4- 

Note  that  restricting  Try  Twice  g)  Client  to  its  compatible  states  cor¬ 
responds  to  imposing  an  assumption  on  the  environment,  namely,  that 
calls  to  the  method  “send”  never  return  twice  in  a  row  the  value  “nack.  ” 
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Hence,  when  the  two  interfaee  automata  TryTwice  and  Client  are  eom- 
posed,  the  assumption  of  Client  that  no  failures  oceur  is  translated  into 
the  assumption  of  Try  Twiee\\  Client  that  no  two  consecutive  transmis¬ 
sions  fail.  The  illustrates  how  the  composition  of  the  interface  automata 
TryTwiee  and  Client  propagates  to  the  environment  of  Try  Twiee\\  Client 
the  assumptions  that  are  neeessary  for  the  eorreet  interaction  of  TryTwice 
and  Client. 

The  definition  of  composition  removes  only  transitions,  not  states, 
from  the  product  automaton.  The  removal  of  transitions,  however,  may 
render  some  states  unreachable,  which  can  then  be  removed  also.  In  par¬ 
ticular,  as  far  as  reachable  states  are  concerned,  the  composition  F\\G 
results  from  the  product  T  (g)  G  by  removing  all  incompatible  states;  if 
the  result  is  empty,  then  F  and  G  are  not  compatible.  In  general,  the 
removal  of  input  transitions  from  a  product  automaton  may  render  even 
some  compatible  states  unreachable.  Hence,  the  relevant  states  of  the 
composite  automaton  F\\G  are  those  states  of  the  product  automaton 
T(g)G  which  remain  reachable  after  all  incompatible  states  are  removed. 
Those  states  of  the  product  automaton  can  be  found  in  linear  time,  by 
forward  and  backward  traversals  of  the  underlying  graph  [5].  Thus  the 
compatibility  of  two  interface  automata  with  mi  and  m2  reachable  tran¬ 
sitions,  respectively,  can  be  checked,  and  their  composition  constructed, 
in  time  0(mi  •  m2). 

The  following  theorem  shows  that  interface  automata  support  incre¬ 
mental  design. 

Theorem  17  For  all  interface  automata  F ,  G,  H ,  and  I,  if  F  ^  G  and 
Hr~.IandF\\G  ~  H\\I ,  then  F  H  and  G  I  and  F\\H  ~  G\\I. 

Proof  sketeh.  For  composability,  note  that  from  the  premises  of  the 
theorem  it  follows  that  Af  is  disjoint  from  Aj  for  all  j  7^  i,  that  all  AFs 
are  pairwise  disjoint,  and  that  all  Af's  are  pairwise  disjoint.  Consider 
the  product  automaton  F  ^  G  ®  H  g)  /;  the  associativity  of  g  implies 
that  parentheses  do  not  matter.  Define  a  state  {pi,P2,P3,P4:)  to  be  an 
error  state  ofTgGgT/gl  if  some  pair  {pi,Pj)  is  an  error  state  of 
the  corresponding  subproduct;  e.g.,  if  {pi^pz)  is  an  error  state  oi  F  ®H. 
Define  a  state  p  to  be  an  incompatible  state  ofTgGgifgl  if  some 
error  state  oiF®G®HdS)I  is  autonomously  reachable  from  p,  that  is, 
reachable  via  hidden  and  output  transitions.  For  £  >  0,  define  a  state 
p  to  be  a  rank-£  incompatible  state  if  some  error  state  is  autonomously 
reachable  from  p  in  at  most  f.  transitions. 

We  show  that  under  the  premises  of  the  theorem,  the  composition 
T||G||H||/  is  achieved,  for  any  insertion  of  parentheses,  by  removing 
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the  incompatible  states  from  the  product  F  0  G  0  H  0  I.  The  proof 
proceeds  in  two  steps.  First,  we  show  that  if  some  projection  of  a  product 
state  p  =  {pi,P2,P3,Pi)  is  an  incompatible  state  of  the  corresponding 
subproduct  (say,  F  (g)  G),  then  p  is  an  incompatible  state  of  the  full 
product  F<SiG<SiH i^iF  Second,  we  show  that  if  p  is  an  incompatible  state 
of  F ig)/,  and  some  input  transitions  are  removed  by  constructing 
the  composition  of  any  subproduct  (say,  F\\H),  then  even  in  the  product 
without  the  removed  transitions,  there  remains  an  autonomous  path 
from  p  to  an  error  state. 

(1)  Consider  a  state  p  of  the  product  Fig)G(g)F (g)/,  and  a  projection  p' 
of  p  which  is  a  rank-.^  incompatible  state  of  the  corresponding  subprod¬ 
uct.  We  show  that  p  is  a  rank-£'  incompatible  state  ofFig)G(g)Ff0/ 
for  some  F  <  L  Consider  a  shortest  autonomous  path  from  p'  to  an 
error  state  in  the  subproduct.  There  are  three  cases.  First,  if  p'  is  an 
error  state  of  the  subproduct  (rank  0),  then  p  is  an  error  state  of  the 
full  product.  Second,  if  the  first  transition  of  the  error  path  from  p'  in 
the  subproduct  corresponds  to  an  output  or  hidden  transition  of  the  full 
product,  then  the  rank  of  the  successor  state  is  £—1  and  the  claim  follows 
by  induction.  Third,  if  the  first  transition  of  the  error  path  from  p'  is 
an  output  transition  of  the  subproduct  which  does  not  have  a  matching 
input  transition  in  the  full  product,  then  p  is  an  error  state  of  the  full 
product  and  has  rank  0. 

(2)  Consider  an  incompatible  state  p  of  the  product  F  ®  G  ®  H  ®  F 
Suppose  that  some  input  transitions  are  removed  by  constructing  the 
composition  of  a  subproduct,  and  remove  the  corresponding  transitions 
in  the  full  product  F®G®H®F  The  only  kind  of  transition  that  might 
be  removed  in  this  way  is  a  hidden  transition  {q,  a,  r)  of  the  product 
whose  projection  onto  the  subproduct  is  an  input  transition  {q',a,r'), 
which  is  matched  in  the  full  product  by  an  output  transition.  Once 
(g,  a,  r)  is  removed,  the  input  action  a  is  no  longer  enabled  at  the  state  q' , 
because  interface  automata  are  input-deterministic.  Hence  in  the  full 
product,  the  state  q  is  an  error  state.  Therefore  even  after  the  removal 
of  the  transition  (g,  a,  r)  from  the  product  F  (g)  G  (g)  Ff  (g)  I,  there  is  an 
autonomous  path  from  p  to  an  error  state,  namely,  to  g.  □ 

As  a  consequence  of  Theorem  17,  we  can  check  whether  A:  >  0  inter¬ 
face  automata  Fi, ...  ,Fk  are  compatible  by  computing  their  composition 
Fill  •  •  •  ||Ffc  incrementally,  by  adding  one  interface  automaton  at  a  time. 
The  potential  efficiency  of  the  incremental  product  construction  lies  in 
the  fact  that  product  states  can  be  pruned  as  soon  as  they  become  ei¬ 
ther  incompatible,  or  unreachable  through  the  pruning  of  incompatible 
states.  Thus,  in  some  cases  the  exponential  explosion  of  states  inherent 
in  a  product  construction  may  be  avoided. 
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Figure  5.  The  interface  automaton  OnceOrTwice. 

Refinement.  In  the  stateful  input-enabled  setting,  refinement  is 
usually  defined  as  trace  containment  or  simulation;  this  ensures  that  all 
output  behaviors  of  the  implementation  are  allowed  by  the  specification. 
However,  such  definitions  are  not  appropriate  in  a  non-input-enabled  set¬ 
ting,  such  as  interface  automata;  if  one  were  to  require  that  the  set  of 
accepted  inputs  of  the  implementation  is  a  subset  of  the  inputs  allowed 
by  the  specification,  then  the  implementation  would  make  stronger  as¬ 
sumptions  about  the  environment,  and  could  not  be  used  in  all  contexts 
in  which  the  specification  is  used. 

Example  18  Consider  the  interface  automaton  OnceOrTwice  of  Fig¬ 
ure  5.  This  automaton  represents  a  component  that  provides  two  ser¬ 
vices:  the  first  is  the  try-twice  service  “send”  provided  also  by  the  au¬ 
tomaton  TryTwice  of  Figure  1;  the  second  is  a  try-once-only  service 
“once”  designed  for  messages  that  are  useless  when  stale.  Clearly,  we 
would  like  to  define  refinement  so  that  OnceOrTwice  is  a  refinement 
of  TryTwice,  because  the  component  OnceOrTwice  implements  all  ser¬ 
vices  provided  by  the  component  TryTwice,  and  it  is  consistent  with 
TryTwice  in  their  implementation.  Hence,  in  all  contexts  in  which 
TryTwice  is  used,  OnceOrTwice  can  be  used  instead.  The  language  of 
OnceOrTwice,  however,  is  not  contained  in  the  language  of  TryTwice; 
indeed,  “once”  is  not  even  an  action  of  TryTwice. 

Therefore,  for  interface  automata  we  define  refinement  in  a  contravari- 
ant  fashion;  the  implementation  must  accept  more  inputs,  and  provide 
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fewer  outputs,  than  the  specification.  For  efficient  checkability  of  re¬ 
finement,  we  choose  a  contravariant  refinement  relation  in  the  spirit  of 
simulation,  rather  than  in  the  spirit  of  language  containment.  This  leads 
to  the  definition  of  refinement  as  alternating  simulation  [1].  Roughly,  an 
interface  automaton  F'  refines  an  interface  automaton  F  if  each  input 
transition  of  F  can  be  simulated  by  F' ,  and  each  output  transition  of  F' 
can  be  simulated  by  F.  The  precise  definition  must  take  into  account 
the  hidden  transitions  of  F  and  F' . 

The  environment  of  an  interface  automaton  F  cannot  see  the  hidden 
transitions  of  F.  Consequently,  if  T  is  at  a  state  q,  and  state  r  is  invisibly 
reachable  from  q  (by  hidden  actions  only),  then  the  environment  cannot 
distinguish  between  q  and  r.  Given  a  state  q  ^  Q,\ei  e- closure (q)  be 
the  set  of  states  that  are  invisibly  reachable  from  q.  The  environment 
must  be  able  to  accept  all  output  actions  in  the  set 

obsA^{q)  =  {a  G  A'^  \  (3r  €  s- closure (q)) {a  G  A^{r))} 

of  outputs  that  may  follow  after  some  sequence  of  hidden  transitions 
from  q.  Conversely,  the  environment  can  safely  issue  all  input  actions  in 
the  set 


obsA^{q)  =  {a  G  A^  \  (Vr  G  £- closure (q)) {a  G  A^ (r))} 

of  inputs  that  are  accepted  after  all  sequences  of  hidden  transitions 
from  q.  For  an  implementation  state  q'  to  refine  a  specification  state  q  we 
need  to  require  that  obsA\q)  C  ohsA\q')  and  ohsA^{q)  D  obsA^{q'). 
Alternating  simulation  propagates  this  requirement  from  q  and  q'  to 
their  successor  states. 

To  define  alternating  simulation  formally,  we  use  the  following  nota¬ 
tion.  Given  a  state  q  G  Q  and  an  action  a  G  A  of  an  interface  automaton, 
let  post{q,  a)  =  {r  G  Q  \  {q,  a,  r)  G  6}  be  the  set  of  a-successors  of  q. 

Definition  19  Given  two  interface  automata  F  and  F' ,  a  binary  rela¬ 
tion  >:  C  Qp  X  Qf'  is  an  alternating  simulation  by  F  oi  F'  if  q  F  q' 
implies 

1.  for  all  input  actions  a  G  A^{q)  and  states  r  G  post(q,a),  there  is  a 
state  r'  G  post{q',a)  such  that  r  >:  r' ; 

2.  for  all  output  actions  a  G  A^{q')  and  states  r'  G  post{q',a),  there 
is  a  state  p  G  e-closure{q)  and  a  state  r  G  post{p,a)  such  that 
r  F  F ; 

3.  for  all  hidden  actions  a  G  A^{q')  and  states  r'  G  post{q\a),  there 
is  a  state  r  G  e-closure{q)  such  that  r  Fr' . 
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Conditions  (1)  and  (2)  express  the  input/output  duality  between 
states  q  q' m.  the  alternating  simulation  relation:  every  input  transi¬ 
tion  from  q  must  be  matched  by  an  input  transition  from  q\  and  every 
output  transition  from  q'  must  be  matched  by  a  sequence  of  zero  or  more 
hidden  transitions  from  q  followed  by  an  output  transition.  Condition  (3) 
stipulates  that  every  hidden  transition  from  q'  can  be  matched  by  a  se¬ 
quence  of  zero  or  more  hidden  transitions  from  q.  In  all  three  cases, 
matching  requires  that  the  alternating-simulation  relation  is  propagated 
co-inductively.  Since  interface  automata  are  input-deterministic,  condi¬ 
tion  (1)  can  be  rewritten  as  (la)  A\q)  C  (q')  and  (lb)  for  all  input 
transitions  {q,  a,  r),  {q' ,  a,  r')  G  5^ ,  we  have  r  ^  r' .  It  can  be  checked  that 
A  q'^  q'  for  some  alternating  simulation  then  obsA\q)  C  obsA\q') 
and  ohsA'^{q)  D  ohsA‘^{q'). 

Definition  20  An  interface  automaton  F'  refines  an  interface  automa¬ 
ton  F ,  written  F  F  F' ,  if 

1.  A^pF  A^p,  and  A^  D  A^,; 

2.  there  is  an  alternating  simulation  F  by  F  of  F'  such  that  qp  F  qp,. 

Note  that  unlike  in  standard  simulation,  the  “typing”  condition  (1) 
is  contravariant  on  the  input  and  output  action  sets.  This  captures  a 
simple  kind  of  subclassing:  if  T  ^  T',  then  the  implementation  F'  is 
able  to  provide  more  services  than  the  specification  F,  but  it  must  be 
consistent  with  F  on  the  shared  services.  Condition  (2)  relates  the  initial 
states  of  the  two  automata. 

Example  21  In  the  example  of  Figures  1  and  5,  there  is  an  alternating 
simulation  that  relates  q  with  q'  for  all  q  G  {0, 1,  2, 3, 4,  5, 6}.  Hence 
OnceOrTwice  refines  TryTwice. 

It  can  be  shown  that  refinement  relation  between  interface  automata 
is  a  preorder.  Refinement  can  be  checked  in  polynomial  time.  More 
precisely,  if  F  has  ni  reachable  states  and  mi  reachable  transitions,  and 
F'  has  112  reachable  states  and  m2  reachable  transitions,  then  it  can  be 
checked  in  time  0((mi  -|-  m2)  •  (ni  +  n2))  whether  F  F  F'  [1]. 

The  following  theorem  shows  that  interface  automata  support  inde¬ 
pendent  implement  ability:  we  can  always  replace  an  interface  automaton 
F  with  a  more  refined  version  F'  such  that  F  F  F',  provided  that  F  and 
F'  are  connected  to  the  environment  by  the  same  inputs.  The  side  con¬ 
dition  is  due  to  the  fact  that  if  the  environment  were  to  provide  inputs 
for  F'  that  are  not  provided  for  F,  then  it  would  be  possible  that  new 
incompatibilities  arise  in  the  processing  of  these  inputs.  For  software 
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components,  independent  implementability  is  a  statement  of  subclass 
polymorphism:  we  can  always  substitute  a  subclass  for  a  superclass, 
provided  no  new  methods  of  the  subclass  are  used. 

Theorem  22  Consider  three  interface  automata  F ,  G,  and  F'  such  that 
F  and  G  are  composable  and  shared{F\G)  C  shared{F,G).  If  F  ^  G 
and  F  F  F' ,  then  F' ^  G  and  F\\G  F  F'\\G. 

Proof  sketch.  The  typing  conditions  are  straight-forward  to  check. 
Note  in  particular  that  shared {F ' ,  G)  C  shared{F,  G)  implies  both  Ap,  n 
Ag  =  0  and  (A^pAAf)  n  y4g  =  0. 

To  prove  that  F'  ^  G  under  the  premises  of  the  theorem,  we  show  that 
every  autonomous  path  leading  from  the  initial  state  to  an  error  state  of 
F'  OG  can  be  matched,  transition  by  transition,  by  an  autonomous  path 
leading  from  the  initial  state  to  an  error  state  ol  F  ®G.  The  interesting 
case  is  that  of  an  input  transition  of  F'  in  the  product  F'  ®  G,  say  on 
action  a.  Since  the  path  is  autonomous,  the  input  action  a  of  F'  must  be 
an  output  action  of  G,  and  because  shared{F' ,G)  C  shared{F,G),  the 
action  a  must  also  be  an  input  action  of  F.  If  a  is  not  enabled  in  F,  then 
we  have  already  hit  an  error  state  of  T  (8)  G;  otherwise,  there  are  unique 
a-successors  in  both  F  and  F',  and  the  path  matching  can  continue. 

Finally,  to  prove  that  F\\G  F  F'||G  under  the  premises  of  the  theo¬ 
rem,  consider  an  alternating  simulation  ^  by  F  of  F'  such  that  qp  F  qp,. 
Then  an  alternating  simulation  F'  by  F\\G  of  F'\\G  can  be  defined  as 
follows:  let  {p,r)  F'  {p',F)  iff  (1)  p  F  p\  (2)  r  =  r',  and  (3)  (p,  r)  is  not 
an  error  state  of  F  ^  G.  □ 

The  property  of  independent  implementability  implies  that  refinement 
is  compositional:  in  order  to  check  if  F\\G  F  F'\\G' ,  it  suffices  to  check 
both  F  F  F'  and  G  F  G' .  This  observation  allows  the  decomposition 
of  refinement  proofs.  Decomposition  is  particularly  important  in  the 
case  of  interface  automata,  where  the  efficiency  of  refinement  checking 
depends  on  the  number  of  states. 

Discussion 

An  interface  automaton  represents  both  assumptions  about  the  envi¬ 
ronment,  and  guarantees  about  the  specified  component.  The  environ¬ 
ment  assumptions  are  twofold:  (1)  each  output  transition  incorporates 
the  assumption  that  the  corresponding  action  is  accepted  by  the  envi¬ 
ronment  as  input;  and  (2)  each  input  action  that  is  not  accepted  at 
a  state  encodes  the  assumption  that  the  environment  does  not  provide 
that  input.  The  component  guarantees  correspond  to  possible  sequences 
and  choices  of  input,  output,  and  hidden  actions,  as  usual.  When  two 
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interface  automata  are  composed,  the  composition  operator  ||  combines 
not  only  the  component  guarantees,  as  is  the  case  in  other  component 
models,  but  also  the  environment  assumptions. 

Whenever  two  interface  automata  F  and  G  are  compatible,  there 
is  a  particularly  simple  legal  environment,  namely,  the  empty  closure 
close{F,  G).  This  points  to  a  limitation  of  interface  automata;  while  the 
environment  assumption  of  an  automaton  can  express  which  inputs  may 
occur,  it  cannot  express  which  inputs  must  occur.  Thus,  the  environ¬ 
ment  that  provides  no  inputs  is  always  the  best  environment  for  showing 
compatibility.  There  are  several  ways  of  enriching  interface  automata  to 
specify  inputs  that  must  occur,  among  them,  synchronicity  [3,6],  adding 
fairness  [4],  or  adding  real-time  constraints  [7].  In  these  cases,  no  generic 
best  environment  exists,  and  a  legal  environment  must  be  derived  as  a 
winning  strategy  in  a  two-player  game.  Recall  that  two  interfaces  F 
and  G  are  compatible  iff  the  environment  has  a  strategy  to  avoid  in¬ 
compatible  states  of  the  product  F  (X)  G.  In  this  game,  player-1  is  the 
environment,  which  provides  inputs  to  the  product  F  ^G,  and  player-2 
is  the  “team”  {F,  G}  of  interfaces,  which  choose  internal  transitions  and 
outputs  of  F  X)  G.  The  game  aspect  of  compatibility  checking  is  illus¬ 
trated  by  the  following  example  of  a  stateful,  synchronous  extension  of 
assume/guarantee  interfaces  [3]. 

Example  23  Suppose  that  F  and  G  are  two  generalized  A/G  interfaces, 
which  receive  inputs  and  issue  outputs  in  a  sequence  of  rounds  and  may 
change,  in  each  round,  their  input  assumptions  and  output  guarantees. 
The  interface  F  has  no  inputs  and  the  single  output  variable  x;  the 
interface  G  has  the  two  input  variables  x  and  y,  and  no  outputs.  In  the 
first  round,  the  interface  F  either  goes  to  state  go  and  outputs  x  =  0,  or 
it  goes  to  state  qi  and  outputs  x  0.  Also  in  the  first  round,  on  input 
y  =  0  the  interface  G  goes  to  state  vq,  and  on  input  y  0  it  goes  to 
state  ri .  In  the  second  round,  in  state  qo  the  interface  F  outputs  x  =  0, 
and  in  state  qi  it  outputs  x  0,  after  which  it  goes  back  to  the  initial 
state.  Also  the  second  round,  in  state  uq  the  interface  G  has  the  input 
assumption  x  =  0,  and  in  state  ri  it  has  the  input  assumption  x  0. 
After  the  second  round,  also  G  returns  to  its  initial  state  and  the  process 
repeats  ad  infinitum. 

Note  that  the  state  qo  of  interface  F  is  compatible  with  the  state  vq 
of  interface  G,  and  qi  is  compatible  with  ri,  but  qo  is  not  compatible 
with  ri,  and  qi  is  not  compatible  with  tq.  The  environment  provides 
the  input  y  to  the  interface  G  in  every  round.  The  environment  can 
avoid  incompatibilities  by  copying,  in  each  (odd)  round,  the  value  of  x 
into  y.  In  this  way  the  environment  can  ensure  that  F  and  G  are  always 
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in  compatible  states.  Hence  the  two  interfaces  F  and  G  are  compatible. 
The  helpful  strategy  of  the  environment  can  be  synthesized  as  a  winning 
strategy  of  the  two-player  game  “environment”  versus  “interfaees.  ”  In 
this  simple  example,  it  is  a  game  with  complete  information,  because  at 
all  times  the  environment,  by  observing  the  output  x  of  F,  can  deduce 
the  internal  state  of  F. 

In  the  presence  of  hidden  transitions,  interface  languages  must  be 
designed  carefully.  This  is  because  if  the  state  of  an  interface  is  not 
visible  to  the  environment,  then  a  legal  environment  corresponds  to  a 
winning  strategy  in  a  game  with  partial  information.  The  derivation 
of  such  strategies  requires,  in  general,  exponential  time,  by  involving  a 
subset  construction  that  considers  all  sets  of  possible  interface  states  [9]. 
Any  model  with  an  exponential  cost  for  binary  composition,  however,  is 
unlikely  to  be  practical.  This  is  why  we  have  focused,  in  this  article,  on 
the  asynchronous  case  with  hidden  transitions,  and  elsewhere  [3,6,7],  on 
more  general,  synchronous  and  real-time  interfaces  but  without  hidden 
transitions.  Another  interesting  direction  is  to  investigate  stronger  but 
more  efficient  compatibility  checks,  which  consider  only  restricted  sets  of 
strategies  for  the  environment.  Such  checks  would  be  conservative  (i.e., 
sufficient  but  not  necessary)  yet  might  still  achieve  the  desired  properties 
of  incremental  design  and  independent  implementability. 

Rich,  stateful  interfaces  as  games  have  been  developed  further  in  [2, 
4].  In  the  former  article,  multiple  instances  of  a  component,  such  as  a 
recursive  software  module,  may  be  active  simultaneously.  Compatibility 
checking  for  the  corresponding  interface  language  is  based  on  solving 
push-down  games.  In  the  latter  article,  the  notion  of  error  state  is  gen¬ 
eralized  to  handle  resource  constraints  of  a  system:  an  error  occurs  if 
two  or  more  components  simultaneously  access  or  overuse  a  constrained 
resource.  Critical  resources  may  include  power,  buffer  capacity,  or  cost. 
While  the  basic  set-up  of  the  game  “environment”  versus  “interfaces” 
remains  the  same,  the  objective  function  of  the  game  changes  and  may 
include  quantitative  aspects,  such  as  minimizing  resource  use. 
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Notes 

1.  It  is  important  to  emphasize  the  existential  interpretation  of  the  free  inputs  of  in¬ 
terfaces,  because  this  deviates  from  the  standard,  universal  interpretation  of  free  inputs  in 
specifications  [5].  While  a  specification  of  an  open  system  is  well-formed  if  it  can  be  realized 
for  all  input  values,  an  interface  is  well-formed  if  it  is  compatible  to  some  environment.  In 
other  words,  for  interfaces,  the  environment  is  helpful,  not  adversarial. 

2.  We  could  formalize  the  property  of  incremental  design,  instead,  as  associativity  of  in¬ 
terface  composition  [5].  We  chose  our  formalization,  because  it  does  not  require  an  explicit 
notion  of  equality  or  equivalence  between  interfaces.  Implicitly,  according  to  our  formaliza¬ 
tion,  two  interfaces  F  and  G  are  equivalent  if  they  are  compatible  with  same  interfaces,  that 
is,  if  for  all  interfaces  H,  we  have  F  H  iS  G  H.  It  can  be  shown  that  if  the  property 
of  incremental  design  holds,  then  for  all  interfaces  F,  G,  and  ff,  if  ~  G  and  F\\G  ^  H, 
then  G  H  and  F  ~  G\\H  and  the  two  interfaces  (_F||G)||/f  and  _F||(G||/f)  are  equivalent 
in  the  specified  sense. 

3.  A  discussion  about  interfaces  versus  components  can  be  found  in  [6]. 

4.  The  property  of  independent  implementability  is  a  compositionality  property  [6].  It 
should  be  noted  that  the  “direction”  of  interface  compositionality  is  top-down,  from  more 
abstract  to  more  refined  interfaces:  if  F  G  and  F  y  F'  and  G  ^  G',  then  F'  G' .  This 
is  in  contrast  to  the  bottom-up  compositionality  of  many  other  formalisms:  if  F'  ~  G'  and 
F'  A  F  and  G'  ^  G,  then  F  G. 
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